Full Disk Encryption: BitLocker vs LUKS Setup Guide

TL;DR: Full disk encryption protects your data if a laptop is lost or stolen. On Windows, use BitLocker (built into Pro/Enterprise, tied to your TPM). On Linux, use LUKS with cryptsetup — it's the standard on Ubuntu, Fedora, and most distros. Both use AES encryption and can unlock automatically via TPM, but LUKS gives you more control and BitLocker gives you less friction on a stock Windows box.

I get asked this every time someone hands off a laptop for a new hire or ships a machine to a remote employee: "do we really need full disk encryption, and which one do we use?" Short answer — yes, always, and it depends on the OS. This post walks through setting up both BitLocker and LUKS properly, not just clicking "enable" and hoping for the best.

What full disk encryption actually protects you from

Full disk encryption (FDE) encrypts the entire storage volume — OS, apps, your files, swap, the works — so that without the key, the disk just looks like noise. It protects you against one specific threat: someone with physical access to the powered-off drive. Pull the SSD out of a stolen laptop, plug it into another machine, and without the key you get nothing.

It does not protect you from malware running on a logged-in session, a weak login password, or someone shoulder-surfing your unlock PIN. Don't let FDE be your only control — pair it with screen lock, a real password policy, and endpoint protection.

BitLocker setup on Windows

BitLocker ships with Windows 10/11 Pro, Enterprise, and Education (some newer OEM Home devices with modern hardware get a lighter version called Device Encryption, which auto-enables when you sign in with a Microsoft account). You need:

TPM 1.2 or 2.0, enabled in UEFI/BIOS
UEFI boot mode (not legacy BIOS)
Admin rights

GUI method (fastest for a single machine)

Start > type "BitLocker" > Manage BitLocker > turn it on for your C: drive. You'll be asked how to back up the recovery key (Microsoft account, file, print, or USB) — pick one you'll actually still have access to in six months. Don't just save it to a file on the same drive you're encrypting.

Command-line method (manage-bde) — better for scripting or a fleet

Open an elevated Command Prompt or PowerShell. Check status first:

manage-bde -status

Turn on encryption with a recovery password and save the recovery key to another drive:

manage-bde -on C: -recoverykey E:\ -recoverypassword

For unattended deployment (MDT/SCCM-style, during Windows PE) where you want to skip the hardware compatibility test:

manage-bde -on C: -usedspaceonly -skiphardwaretest

-usedspaceonly only encrypts space that has data — much faster on a fresh install, since free space gets encrypted anyway the first time something's written there. On a machine that's already been in use with sensitive data on it, encrypt the full drive instead (drop that flag) so nothing lingers unencrypted in previously-used sectors.

To check on a data drive or add a password protector to it:

manage-bde -status D:
manage-bde -protectors -add D: -password

Locking and unlocking manually (useful when troubleshooting a drive that won't auto-unlock):

manage-bde -lock D:
manage-bde -unlock D: -recoverypassword 123456-123456-123456-123456-123456-123456-123456-123456

If you ever see BitLocker demand the recovery key unexpectedly on a machine that's unlocked itself for months, don't panic and don't just enter the key and move on — check whether the TPM measurements changed (BIOS update, Secure Boot toggle, boot order change). That's almost always the cause, and it's worth knowing before it happens again.

TPM + PIN for laptops that travel

TPM-only unlock is convenient but means anyone who can power on the laptop gets past BitLocker's first line of defense — Windows login is still there, but you've lost the "cold boot needs a secret" protection. For anything leaving the building, add a PIN:

manage-bde -protectors -add C: -TPMAndPIN

This requires Secure Boot to be enabled and Group Policy to allow "Enhanced PINs" if you want special characters in it.

LUKS setup on Ubuntu (and other Linux distros)

LUKS (Linux Unified Key Setup) is the standard disk-encryption format on Linux, managed with the cryptsetup tool. It's what Ubuntu's installer uses under the hood when you check "Encrypt the new Ubuntu installation."

Easiest path: encrypt during install

Boot the Ubuntu installer, choose "Erase disk and install Ubuntu," then check "Advanced features…" and pick "Use LVM with encryption." You'll set a passphrase, and the installer handles LUKS + LVM (root and swap as logical volumes on top of the encrypted container) for you. This is what I'd tell almost anyone doing a fresh laptop install to use — no reason to hand-roll it unless you have a specific partition layout in mind.

Ubuntu 24.04 LTS also introduced an experimental TPM-backed FDE option in the installer (look for "Use TPM-backed full disk encryption" under Advanced features). It seals the LUKS key to the TPM so the disk unlocks automatically at boot, similar to how BitLocker works with a TPM-only protector — no passphrase typed at boot, but the same tradeoff: someone who can power the machine on gets past the disk-level gate. As of this writing Canonical still documents it as a beta feature with known limitations, so check the current status before relying on it for anything you can't easily rebuild.

Manual LUKS setup on a secondary drive or non-root partition

Install the tool first:

sudo apt install cryptsetup

Format the partition as a LUKS container. This destroys any existing data on it — there's no encrypting a partition "in place":

sudo cryptsetup luksFormat /dev/sdb1

You'll get a warning and have to type YES in capitals, then set a passphrase:

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdb1:
Verify passphrase:

Open it (this creates a decrypted mapping under /dev/mapper):

sudo cryptsetup luksOpen /dev/sdb1 encrypted_disk

Format the decrypted device and mount it like any other:

sudo mkfs.ext4 /dev/mapper/encrypted_disk
sudo mount /dev/mapper/encrypted_disk /mnt/data

LUKS on LVM (the layout Ubuntu's installer actually uses)

If you're doing a manual root-partition setup — say, a custom partition scheme or dual-boot layout the installer's automatic option won't produce — the flow is: encrypt the raw partition first, then build LVM on top of the decrypted mapping.

sudo cryptsetup luksFormat /dev/nvme0n1p3
sudo cryptsetup open /dev/nvme0n1p3 cryptroot
sudo pvcreate /dev/mapper/cryptroot
sudo vgcreate vgubuntu /dev/mapper/cryptroot
sudo lvcreate -L 8G -n swap vgubuntu
sudo lvcreate -l 100%FREE -n root vgubuntu

One gotcha that trips people up on multi-boot or custom-layout installs: as of recent Ubuntu releases, GRUB can only unlock a LUKS1 container, not LUKS2, if /boot itself is on an encrypted volume. If you're keeping /boot unencrypted (the simpler, more common setup) this doesn't matter — LUKS2 is the current default and fine for the root/data partitions. It only bites you if you're trying to encrypt /boot too.

Checking status and managing keys

sudo cryptsetup status encrypted_disk
sudo cryptsetup luksDump /dev/sdb1

Add a second passphrase (handy for shared admin access or key rotation) without needing to decrypt and re-encrypt anything:

sudo cryptsetup luksAddKey /dev/sdb1

Back up the LUKS header before you do anything risky. A corrupted header means the data is gone even if the passphrase is fine — this file is genuinely your only recovery path if that happens:

sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/luks-header-backup.bin

Store that backup file off the encrypted disk. Obvious in hindsight, but I've seen it saved right back onto the drive it's backing up, which defeats the entire point.

BitLocker vs LUKS: how they actually compare

Factor	BitLocker	LUKS
Platform	Windows Pro/Enterprise/Education (Device Encryption on some Home SKUs)	Linux — Ubuntu, Fedora, Debian, most distros
Setup path	Control Panel GUI or manage-bde CLI	Installer checkbox or manual cryptsetup
TPM auto-unlock	Mature, standard since Windows 8	Experimental (Ubuntu 24.04+), or via clevis/systemd-cryptenroll
Encryption	AES-128/256, XTS or CBC mode	AES-XTS by default, configurable cipher/hash/KDF
Recovery key format	48-digit numerical recovery password	Passphrase, keyfile, or header backup
Fleet management	Group Policy, Intune, Active Directory key escrow	Ansible/Puppet, or key servers with keyfiles
Multiple unlock methods per volume	Yes — TPM, PIN, password, USB key, recovery key	Yes — up to 8 key slots per LUKS1 header, more on LUKS2

If you're on stock Windows hardware with a TPM, BitLocker is the obvious choice — it's already there, it's well-tested, and it plugs into Group Policy and Intune for fleet management. On Linux, LUKS is really the only mainstream option, and honestly it's just as solid; you get more manual control over cipher and key derivation settings, at the cost of TPM auto-unlock being a newer, less battle-tested feature than BitLocker's.

Common mistakes I see

Saving the recovery key nowhere retrievable. A recovery key saved only to the encrypted drive itself, or to a Microsoft/company account nobody remembers the login for, might as well not exist.
Assuming TPM-only unlock is "good enough." It protects against a stolen powered-off drive. It does nothing once the machine is running and logged in, or if someone can just power it on and get to the login screen.
Forgetting swap. An unencrypted swap partition can leak memory contents — passwords, keys, whatever was in RAM — to disk. If you're rolling your own LUKS-on-LVM setup, make sure swap is inside the encrypted volume group, not a separate unencrypted partition.
No header backup on LUKS. Losing the LUKS header (bad sectors, accidental overwrite) means the data's gone regardless of whether you remember the passphrase.

FAQ

Does full disk encryption slow down my computer?

On any CPU from the last decade with AES-NI hardware acceleration (check with grep aes /proc/cpuinfo on Linux), the overhead is small enough you won't notice it in daily use. It's mainly disk-write-heavy workloads where you might see a measurable dip.

Can I add BitLocker or LUKS encryption after Windows/Ubuntu is already installed?

Yes for both, with one catch on Linux: you can't encrypt a mounted root partition in place. For an already-installed Ubuntu system, you either need a second disk, or you boot from a live USB, back up your data, and reinstall with encryption enabled. BitLocker, by contrast, can encrypt a live Windows system drive without a reinstall.

What happens if I lose both the passphrase and the recovery key?

The data is gone. That's the entire point of the design — there's no backdoor. Store recovery keys somewhere separate from the device (password manager, printed and locked up, or your organization's AD/Intune key escrow).

Does full disk encryption protect against ransomware?

No. FDE protects data at rest on a powered-off drive. Once you're logged in and the disk is unlocked, ransomware running in your session can read and encrypt your files same as it would on an unencrypted disk.

Is BitLocker available on Windows Home?

Standard BitLocker is Pro/Enterprise/Education only. Some newer Windows 11 Home devices get a lighter "Device Encryption" that turns on automatically when you sign in with a Microsoft account — check Settings > Privacy & Security > Device encryption to see if your machine has it.

Do I need Secure Boot for TPM-backed encryption?

For BitLocker's TPM+PIN mode, yes, Secure Boot is required. For basic TPM-only BitLocker, it's strongly recommended. For Ubuntu's TPM-backed FDE, Secure Boot is part of how the boot chain gets verified before the TPM releases the key — same underlying principle as BitLocker.